Prometheus Metrics: มาตรฐานระดับโลกสำหรับการตรวจสอบประสิทธิภาพแอปพลิเคชันยุคใหม่

ในภูมิทัศน์ดิจิทัลที่เชื่อมโยงถึงกันในปัจจุบัน แอปพลิเคชันเป็นกระดูกสันหลังของธุรกิจทั่วโลก ตั้งแต่สถาบันการเงินที่ประมวลผลธุรกรรมข้ามทวีป ไปจนถึงแพลตฟอร์มอีคอมเมิร์ซที่ให้บริการลูกค้าหลากหลายนับล้านรายทุกวัน ความน่าเชื่อถือและประสิทธิภาพของซอฟต์แวร์เป็นสิ่งสำคัญยิ่ง การตรวจสอบประสิทธิภาพแอปพลิเคชัน (APM) ได้พัฒนาจากการเป็นสาขาวิชาเฉพาะทางไปสู่สิ่งจำเป็นในการดำเนินงานที่สำคัญ เพื่อให้มั่นใจว่าระบบที่สำคัญเหล่านี้ทำงานได้อย่างราบรื่น มีประสิทธิภาพ และไม่หยุดชะงัก โดยไม่คำนึงถึงสถานที่ทางภูมิศาสตร์หรือบริบททางวัฒนธรรม

การเปลี่ยนแปลงสถาปัตยกรรมไปสู่กระบวนทัศน์คลาวด์เนทีฟ ไมโครเซอร์วิส และคอนเทนเนอไรเซชัน ได้นำมาซึ่งความซับซ้อนที่ไม่เคยมีมาก่อน ในขณะที่สถาปัตยกรรมเหล่านี้มอบความยืดหยุ่นและความสามารถในการปรับขนาดที่ไม่มีใครเทียบได้ แต่ก็มีความท้าทายใหม่ๆ สำหรับการตรวจสอบด้วย เครื่องมือ APM แบบดั้งเดิม ซึ่งมักออกแบบมาสำหรับแอปพลิเคชันแบบโมโนลิธ จะประสบปัญหาในการให้การมองเห็นที่ครอบคลุมในสภาพแวดล้อมที่มีการกระจายสูงและไม่แน่นอน นี่คือจุดที่ Prometheus ระบบการตรวจสอบแบบโอเพนซอร์สและฐานข้อมูลอนุกรมเวลา (time-series database) ถือกำเนิดขึ้นในฐานะโซลูชันที่พลิกโฉมวงการ กลายเป็นมาตรฐานโดยพฤตินัยสำหรับ APM ในระบบระดับโลกที่ทันสมัยอย่างรวดเร็ว

คู่มือฉบับสมบูรณ์นี้จะเจาะลึก Prometheus Metrics โดยสำรวจความสามารถในการตรวจสอบประสิทธิภาพแอปพลิเคชัน ส่วนประกอบหลัก แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้งาน และวิธีที่ช่วยให้องค์กรทั่วโลกบรรลุการสังเกตการณ์ที่เหนือชั้นและความเป็นเลิศในการดำเนินงาน เราจะหารือถึงความเกี่ยวข้องในสภาพแวดล้อมที่หลากหลาย ตั้งแต่สตาร์ทอัพไปจนถึงบริษัทข้ามชาติ และวิธีที่โมเดลแบบดึง (pull-based model) ที่ยืดหยุ่นเหมาะสมกับความต้องการของโครงสร้างพื้นฐานระดับโลก

Prometheus คืออะไร? ที่มา ปรัชญา และส่วนประกอบหลัก

Prometheus มีต้นกำเนิดที่ SoundCloud ในปี 2555 ในฐานะโครงการภายใน ออกแบบมาเพื่อแก้ไขปัญหาความท้าทายในการตรวจสอบโครงสร้างพื้นฐานที่เปลี่ยนแปลงอย่างรวดเร็วและใช้คอนเทนเนอร์ของตน ได้รับแรงบันดาลใจจากระบบการตรวจสอบ Borgmon ของ Google ต่อมาได้เปิดตัวเป็นโอเพนซอร์สในปี 2558 และเข้าร่วม Cloud Native Computing Foundation (CNCF) อย่างรวดเร็วในฐานะโครงการที่ได้รับการโฮสต์เป็นอันดับสอง รองจาก Kubernetes ปรัชญาของมันหยั่งรากอยู่ในความเรียบง่าย ความน่าเชื่อถือ และความสามารถในการทำงานได้อย่างมีประสิทธิภาพในสภาพแวดล้อมที่มีการเปลี่ยนแปลงอย่างมาก

ซึ่งแตกต่างจากระบบการตรวจสอบแบบดั้งเดิมหลายระบบที่อาศัยเอเจนต์ส่งข้อมูล Prometheus ใช้ โมเดลแบบดึง (pull-based model) มันจะสแกน (scrape) เอนด์พอยต์ HTTP เป็นระยะๆ ตามที่กำหนดไว้เพื่อรวบรวมเมตริก ทำให้เหมาะสมอย่างยิ่งสำหรับแอปพลิเคชันคลาวด์เนทีฟที่เปิดเผยเมตริกของตนผ่านอินเทอร์เฟซ HTTP มาตรฐาน แนวทางนี้ช่วยลดความซับซ้อนในการปรับใช้และการจัดการ โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่โทโพโลยีเครือข่ายเปลี่ยนแปลงบ่อย หรือเมื่อแอปพลิเคชันถูกปรับใช้เป็นคอนเทนเนอร์ที่มีอายุสั้น

ส่วนประกอบสำคัญของระบบนิเวศ Prometheus

พลังของ Prometheus อยู่ในระบบนิเวศของเครื่องมือที่ทำงานร่วมกันได้อย่างลงตัว:

• Prometheus Server: นี่คือหัวใจของระบบ มีหน้าที่สแกนเมตริกจากเป้าหมายที่กำหนดค่าไว้ จัดเก็บเป็นข้อมูลอนุกรมเวลา รันกฎการแจ้งเตือน และให้บริการคิวรี PromQL การจัดเก็บข้อมูลในเครื่องได้รับการปรับให้เหมาะสมอย่างยิ่งสำหรับข้อมูลอนุกรมเวลา
• Exporters: Prometheus ไม่สามารถตรวจสอบแอปพลิเคชันหรือระบบทุกอย่างได้โดยตรง Exporters เป็นแอปพลิเคชันขนาดเล็กที่ทำงานเดียวที่แปลงเมตริกจากแหล่งต่างๆ (เช่น ระบบปฏิบัติการ ฐานข้อมูล คิวข้อความ) ให้อยู่ในรูปแบบที่เข้ากันได้กับ Prometheus โดยเปิดเผยผ่านเอนด์พอยต์ HTTP ตัวอย่าง ได้แก่ node_exporter สำหรับเมตริกระดับโฮสต์ kube-state-metrics สำหรับสุขภาพของคลัสเตอร์ Kubernetes และ exporters ฐานข้อมูลต่างๆ
• Pushgateway: แม้ว่า Prometheus ส่วนใหญ่จะเป็นแบบดึง แต่ก็มีสถานการณ์ โดยเฉพาะอย่างยิ่งกับงานแบตช์ที่ไม่แน่นอนหรือมีอายุสั้น ที่เป้าหมายไม่สามารถสแกนได้อย่างน่าเชื่อถือ Pushgateway อนุญาตให้งานดังกล่าวผลักดันเมตริกของตนไปยังเกตเวย์นี้ ซึ่ง Prometheus จะสแกนต่อไป สิ่งนี้ทำให้มั่นใจได้ว่าเมตริกจากกระบวนการชั่วคราวจะถูกบันทึก
• Alertmanager: ส่วนประกอบนี้จัดการการแจ้งเตือนที่ส่งโดย Prometheus server มันจะทำการ de-duplicate จัดกลุ่ม และส่งต่อการแจ้งเตือนไปยังผู้รับที่เหมาะสม (เช่น อีเมล Slack PagerDuty, VictorOps, webhooks ที่กำหนดเอง) นอกจากนี้ยังรองรับการปิดเสียงการแจ้งเตือนและกฎการยับยั้ง ซึ่งสำคัญต่อการป้องกันพายุการแจ้งเตือนและเพื่อให้แน่ใจว่าทีมที่ถูกต้องได้รับข้อมูลแจ้งเตือนที่เกี่ยวข้อง
• Client Libraries: สำหรับการทำเครื่องหมาย (instrumenting) แอปพลิเคชันที่กำหนดเอง Prometheus มีไลบรารีไคลเอ็นต์สำหรับภาษาโปรแกรมยอดนิยม (Go, Java, Python, Ruby, Node.js, C#, ฯลฯ) ไลบรารีเหล่านี้ช่วยให้นักพัฒนาสามารถเปิดเผยเมตริกที่กำหนดเองจากแอปพลิเคชันของตนในรูปแบบ Prometheus ได้อย่างง่ายดาย
• Grafana: แม้ว่าจะไม่ใช่ส่วนหนึ่งของโปรเจกต์ Prometheus โดยตรง แต่ Grafana เป็นเครื่องมือสร้างภาพที่ใช้กันมากที่สุดและมีประสิทธิภาพที่สุดที่ใช้กับ Prometheus ช่วยให้ผู้ใช้สามารถสร้างแดชบอร์ดที่สมบูรณ์และโต้ตอบได้จากข้อมูล Prometheus นำเสนอข้อมูลเชิงลึกที่ไม่เคยมีมาก่อนเกี่ยวกับประสิทธิภาพของแอปพลิเคชันและโครงสร้างพื้นฐาน

ภาพรวมการทำงาน: ภาพรวมระดับสูง

ลองนึกภาพแพลตฟอร์มอีคอมเมิร์ซระดับโลกที่มีไมโครเซอร์วิสปรับใช้ในหลายภูมิภาคคลาวด์ นี่คือวิธีที่ Prometheus เข้ามามีบทบาท:

• Instrumentation: นักพัฒนาใช้ไลบรารีไคลเอ็นต์ Prometheus เพื่อทำเครื่องหมายไมโครเซอร์วิสของตน (เช่น บริการสินค้าคงคลัง เกตเวย์การชำระเงิน การยืนยันตัวตนผู้ใช้) พวกเขากำหนดเมตริก เช่น http_requests_total (ตัวนับ) request_duration_seconds (ฮิสโตแกรม) และ active_user_sessions (เครื่องวัด)
• การเปิดเผยเมตริก: ไมโครเซอร์วิสแต่ละตัวจะเปิดเผยเมตริกเหล่านี้บนเอนด์พอยต์ HTTP เฉพาะ โดยทั่วไปคือ /metrics
• การสแกน (Scraping): Prometheus servers ที่ปรับใช้ในแต่ละภูมิภาคหรือส่วนกลาง ถูกกำหนดค่าให้ค้นพบและสแกนเอนด์พอยต์ /metrics เหล่านี้เป็นระยะๆ (เช่น ทุกๆ 15 วินาที)
• การจัดเก็บ: เมตริกที่สแกนจะถูกเก็บไว้ในฐานข้อมูลอนุกรมเวลาของ Prometheus เมตริกแต่ละรายการมีชื่อและชุดคู่คีย์-ค่าที่เรียกว่าป้ายกำกับ (labels) ซึ่งช่วยให้สามารถกรองและรวมกลุ่มได้อย่างมีประสิทธิภาพ
• การคิวรี: วิศวกรความน่าเชื่อถือของไซต์ (SREs) และทีม DevOps ใช้ PromQL (Prometheus Query Language) เพื่อคิวรีข้อมูลนี้ ตัวอย่างเช่น พวกเขาอาจคิวรี rate(http_requests_total{job="payment_service", status="5xx"}[5m]) เพื่อดูอัตราข้อผิดพลาด 5xx ต่อนาทีจากบริการชำระเงิน
• การแจ้งเตือน: ตามคิวรี PromQL จะมีการกำหนดกฎการแจ้งเตือนใน Prometheus หากผลลัพธ์คิวรีข้ามเกณฑ์ที่กำหนดไว้ล่วงหน้า (เช่น อัตราข้อผิดพลาดเกิน 1%) Prometheus จะส่งการแจ้งเตือนไปยัง Alertmanager
• การแจ้งเตือน: Alertmanager ประมวลผลการแจ้งเตือน จัดกลุ่มกับการแจ้งเตือนที่คล้ายกัน และส่งการแจ้งเตือนไปยังผู้รับที่เหมาะสมผ่าน Slack, PagerDuty หรืออีเมล โดยอาจมีการส่งต่อให้ทีมอื่นตามระดับความรุนแรงหรือเวลาของวัน
• การสร้างภาพ: แดชบอร์ด Grafana ดึงข้อมูลจาก Prometheus เพื่อแสดงเมตริกประสิทธิภาพแบบเรียลไทม์และแบบย้อนหลัง นำเสนอภาพรวมสุขภาพและพฤติกรรมของแอปพลิเคชันในทุกภูมิภาค

พลังของ Prometheus สำหรับ APM ในบริบทระดับโลก

Prometheus มีข้อได้เปรียบที่โดดเด่นซึ่งทำให้เหมาะสมอย่างยิ่งสำหรับ APM โดยเฉพาะอย่างยิ่งสำหรับองค์กรที่ดำเนินงานในระดับโลกด้วยระบบแบบกระจายที่ซับซ้อน

การมองเห็นในสถาปัตยกรรมสมัยใหม่

แอปพลิเคชันสมัยใหม่มักสร้างขึ้นโดยใช้ไมโครเซอร์วิสที่ปรับใช้ในคอนเทนเนอร์ที่จัดการโดย Orchestrator เช่น Kubernetes ส่วนประกอบเหล่านี้ไม่แน่นอน ขยายขนาดขึ้นและลงอย่างรวดเร็ว และสื่อสารกันผ่านเครือข่าย Prometheus ที่มีกลไกการค้นหาบริการ (service discovery) และโมเดลข้อมูลที่ใช้ป้ายกำกับ (label-based data model) ให้การมองเห็นที่ไม่มีใครเทียบได้ในสภาพแวดล้อมที่เปลี่ยนแปลงเหล่านี้ มันสามารถค้นหาบริการใหม่ๆ โดยอัตโนมัติ ตรวจสอบสุขภาพของบริการเหล่านั้น และให้เมตริกที่อุดมไปด้วยบริบท ช่วยให้ทีมสามารถเข้าใจประสิทธิภาพทั่วทั้งเครือข่ายบริการที่เชื่อมต่อกันที่ซับซ้อน โดยไม่คำนึงถึงตำแหน่งทางกายภาพหรือตรรกะ

การตรวจจับปัญหาเชิงรุกและการวิเคราะห์หาสาเหตุที่แท้จริง

การตรวจสอบแบบดั้งเดิมมักมุ่งเน้นไปที่การตอบสนองต่อเหตุการณ์แบบปฏิกิริยา Prometheus เปลี่ยนกระบวนทัศน์นี้ไปสู่การตรวจจับปัญหาเชิงรุก ด้วยการรวบรวมเมตริกระดับสูงอย่างต่อเนื่องและประเมินกฎการแจ้งเตือน มันสามารถตั้งค่าพฤติกรรมที่ผิดปกติหรือปัญหาที่อาจเกิดขึ้นก่อนที่จะลุกลามกลายเป็นเหตุการณ์ที่ทำให้ระบบล่ม สำหรับบริการระดับโลก สิ่งนี้หมายถึงการระบุการหน่วงเวลาเฉพาะที่ในภูมิภาคใดภูมิภาคหนึ่ง หรือคอขวดด้านประสิทธิภาพในไมโครเซอร์วิสเฉพาะที่อาจส่งผลกระทบต่อผู้ใช้ในเขตเวลาเฉพาะเท่านั้น ช่วยให้ทีมสามารถแก้ไขปัญหาก่อนที่จะส่งผลกระทบต่อฐานผู้ใช้ที่กว้างขึ้น

ข้อมูลเชิงลึกที่นำไปปฏิบัติได้สำหรับทีมที่หลากหลาย

Prometheus ไม่เพียงแต่รวบรวมข้อมูลเท่านั้น แต่ยังช่วยให้สามารถดึงข้อมูลเชิงลึกที่นำไปปฏิบัติได้ด้วย ภาษาคิวรีอันทรงพลัง PromQL ช่วยให้นักวิศวกรสามารถแบ่งและรวมเมตริกตามป้ายกำกับตามอำเภอใจ (เช่น บริการ ภูมิภาค ID ผู้เช่า ศูนย์ข้อมูล เอนด์พอยต์ API เฉพาะ) ความละเอียดนี้มีความสำคัญสำหรับทีมระดับโลกที่ทีมต่างๆ อาจรับผิดชอบบริการหรือภูมิภาคทางภูมิศาสตร์เฉพาะ ทีมพัฒนาในประเทศหนึ่งสามารถวิเคราะห์ประสิทธิภาพของคุณสมบัติที่เพิ่งเปิดตัวใหม่ของตน ในขณะที่ทีมปฏิบัติการในอีกประเทศหนึ่งสามารถตรวจสอบสุขภาพของโครงสร้างพื้นฐาน ทั้งหมดนี้โดยใช้ระบบการตรวจสอบและข้อมูลพื้นฐานเดียวกัน

ความสามารถในการปรับขนาดและความยืดหยุ่นสำหรับการปรับใช้ทั่วโลก

Prometheus ถูกออกแบบมาให้มีความสามารถในการปรับขนาดสูง แม้ว่า Prometheus server เดียวจะมีความแข็งแกร่ง แต่บริษัทขนาดใหญ่ที่กระจายตัวไปทั่วโลกสามารถปรับใช้ Prometheus instances หลายตัว สหพันธ์ (federate) หรือใช้โซลูชันการจัดเก็บระยะยาว เช่น Thanos หรือ Mimir เพื่อให้ได้การรวมกลุ่มระดับโลกและการเก็บข้อมูลระยะยาว ความยืดหยุ่นนี้ช่วยให้องค์กรสามารถปรับโครงสร้างพื้นฐานการตรวจสอบให้เข้ากับความต้องการเฉพาะของตนได้ ไม่ว่าจะเป็นศูนย์ข้อมูลเดียว หรือการมีตัวตนในผู้ให้บริการคลาวด์รายใหญ่ทั้งหมดและสภาพแวดล้อมภายในองค์กรทั่วโลก

ข้อได้เปรียบของโอเพนซอร์ส: ชุมชน ความคุ้มค่า และความโปร่งใส

ในฐานะโครงการโอเพนซอร์ส Prometheus ได้รับประโยชน์จากชุมชนนักพัฒนาและผู้ใช้ทั่วโลกที่มีชีวิตชีวา สิ่งนี้ทำให้มั่นใจได้ถึงนวัตกรรมที่ต่อเนื่อง เอกสารที่แข็งแกร่ง และความรู้ที่แบ่งปันกันมากมาย สำหรับองค์กร สิ่งนี้แปลเป็นความคุ้มค่า (ไม่มีค่าลิขสิทธิ์) ความโปร่งใส (รหัสสามารถตรวจสอบได้) และความสามารถในการปรับแต่งและขยายระบบให้ตรงตามข้อกำหนดที่ไม่ซ้ำกัน รูปแบบที่เปิดกว้างนี้ส่งเสริมความร่วมมือและช่วยให้องค์กรทั่วโลกสามารถมีส่วนร่วมและได้รับประโยชน์จากวิวัฒนาการของมัน

แนวคิด Prometheus หลักสำหรับ APM

เพื่อใช้ประโยชน์จาก Prometheus สำหรับ APM ได้อย่างมีประสิทธิภาพ สิ่งสำคัญคือต้องเข้าใจแนวคิดพื้นฐานของมัน

ประเภทเมตริก: บล็อกการสร้างการสังเกตการณ์

Prometheus กำหนดประเภทเมตริกหลักสี่ประเภท ซึ่งแต่ละประเภทมีวัตถุประสงค์เฉพาะในการบันทึกข้อมูลประสิทธิภาพของแอปพลิเคชัน:

• Counter: เมตริกสะสมที่เพิ่มขึ้นเสมอ (หรือรีเซ็ตเป็นศูนย์เมื่อรีสตาร์ท) เหมาะสำหรับการนับสิ่งต่างๆ เช่น จำนวนคำขอ HTTP ทั้งหมด จำนวนข้อผิดพลาดทั้งหมด หรือจำนวนรายการที่ประมวลผลโดยคิว ตัวอย่างเช่น http_requests_total{method="POST", path="/api/v1/orders"} สามารถติดตามจำนวนการสั่งซื้อที่สำเร็จทั้งหมดทั่วโลก โดยทั่วไปคุณจะใช้ฟังก์ชัน rate() หรือ increase() ใน PromQL เพื่อรับการเปลี่ยนแปลงต่อวินาทีหรือต่อช่วงเวลา
• Gauge: เมตริกที่แสดงค่าตัวเลขเดียวที่สามารถเพิ่มขึ้นหรือลดลงได้ตามอำเภอใจ Gauge เหมาะสำหรับการวัดค่าปัจจุบัน เช่น จำนวนผู้ใช้พร้อมกัน การใช้งานหน่วยความจำปัจจุบัน อุณหภูมิ หรือจำนวนรายการในคิว ตัวอย่างเช่น database_connections_active{service="billing", region="europe-west1"}
• Histogram: Histograms สุ่มตัวอย่างการสังเกต (เช่น ระยะเวลาการตอบสนองหรือขนาดการตอบกลับ) และนับในถัง (buckets) ที่กำหนดค่าได้ พวกมันให้ข้อมูลเชิงลึกเกี่ยวกับการกระจายตัวของค่า ทำให้มีค่าอย่างยิ่งสำหรับการคำนวณ Service Level Indicators (SLIs) เช่น เปอร์เซ็นไทล์ (เช่น ความหน่วงเวลาเปอร์เซ็นไทล์ที่ 99) กรณีการใช้งานทั่วไปคือการติดตามระยะเวลาการตอบสนองของเว็บ: http_request_duration_seconds_bucket{le="0.1", service="user_auth"} จะนับคำขอที่ใช้เวลาน้อยกว่า 0.1 วินาที Histograms มีความสำคัญอย่างยิ่งต่อการทำความเข้าใจประสบการณ์ผู้ใช้ เนื่องจากค่าเฉลี่ยความหน่วงเวลาอาจทำให้เข้าใจผิดได้
• Summary: คล้ายกับ histograms, summaries ก็สุ่มตัวอย่างการสังเกตด้วย อย่างไรก็ตาม พวกมันคำนวณเปอร์เซ็นไทล์ที่กำหนดค่าได้ (เช่น 0.5, 0.9, 0.99) ที่ฝั่งไคลเอ็นต์ในช่วงเวลาที่เลื่อนได้ แม้ว่าจะใช้งานง่ายกว่าสำหรับการคำนวณเปอร์เซ็นไทล์แบบง่าย แต่ก็อาจมีความแม่นยำน้อยกว่าหรือมีประสิทธิภาพน้อยกว่าสำหรับการรวมกลุ่มระหว่างหลายอินสแตนซ์เมื่อเทียบกับ histograms เมื่อรวมกลุ่มใน Prometheus ตัวอย่างอาจเป็น api_response_time_seconds{quantile="0.99"} โดยทั่วไปแล้ว histograms จะเป็นที่ต้องการเนื่องจากความยืดหยุ่นใน PromQL

ป้ายกำกับ (Labels): รากฐานของพลังการคิวรีของ Prometheus

เมตริกใน Prometheus ถูกระบุโดยชื่อเมตริกและชุดของคู่คีย์-ค่าที่เรียกว่าป้ายกำกับ ป้ายกำกับมีประสิทธิภาพอย่างไม่น่าเชื่อ เนื่องจากช่วยให้สามารถสร้างแบบจำลองข้อมูลหลายมิติ แทนที่จะมีเมตริกแยกต่างหากสำหรับภูมิภาคหรือเวอร์ชันบริการที่แตกต่างกัน คุณสามารถใช้ป้ายกำกับได้:

            
http_requests_total{method="POST", handler="/users", status="200", region="us-east", instance="web-01"}
http_requests_total{method="GET", handler="/products", status="500", region="eu-west", instance="web-02"}

            

              
                Copy
              
            
          

สิ่งนี้ช่วยให้คุณสามารถกรอง รวมกลุ่ม และจัดกลุ่มข้อมูลได้อย่างแม่นยำ สำหรับผู้ชมทั่วโลก ป้ายกำกับมีความสำคัญอย่างยิ่งต่อ:

• การวิเคราะห์ตามภูมิภาค: กรองตาม region="asia-southeast1" เพื่อดูประสิทธิภาพในสิงคโปร์
• ข้อมูลเชิงลึกเฉพาะบริการ: กรองตาม service="payment_gateway" เพื่อแยกเมตริกการประมวลผลการชำระเงิน
• การยืนยันการปรับใช้: กรองตาม version="v1.2.3" เพื่อเปรียบเทียบประสิทธิภาพก่อนและหลังการเปิดตัวใหม่ในทุกสภาพแวดล้อม
• การตรวจสอบระดับผู้เช่า (Tenant-Level Monitoring): สำหรับผู้ให้บริการ SaaS ป้ายกำกับสามารถรวม tenant_id="customer_xyz" เพื่อตรวจสอบประสิทธิภาพของลูกค้าเฉพาะ

การวางแผนป้ายกำกับอย่างรอบคอบมีความสำคัญอย่างยิ่งต่อการตรวจสอบที่มีประสิทธิภาพ เนื่องจากจำนวนคาร์ดินาลิตีที่สูง (ค่าป้ายกำกับที่ไม่ซ้ำกันมากเกินไป) อาจส่งผลกระทบต่อประสิทธิภาพและการจัดเก็บของ Prometheus

Service Discovery: การตรวจสอบแบบไดนามิกสำหรับสภาพแวดล้อมแบบไดนามิก

ในสภาพแวดล้อมคลาวด์เนทีฟสมัยใหม่ แอปพลิเคชันกำลังถูกปรับใช้ ปรับขนาด และยกเลิกอย่างต่อเนื่อง การกำหนดค่า Prometheus ด้วยตนเองเพื่อสแกนทุกอินสแตนซ์ใหม่นั้นไม่สามารถทำได้จริงและมีแนวโน้มที่จะเกิดข้อผิดพลาด Prometheus แก้ปัญหานี้ด้วยกลไกการค้นหาบริการที่มีประสิทธิภาพ มันสามารถรวมเข้ากับแพลตฟอร์มต่างๆ เพื่อค้นหาเป้าหมายการสแกนโดยอัตโนมัติ:

• Kubernetes: การผสานรวมที่ใช้กันทั่วไปและมีประสิทธิภาพ Prometheus สามารถค้นหาบริการ พ็อด และเอนด์พอยต์ภายในคลัสเตอร์ Kubernetes ได้
• ผู้ให้บริการคลาวด์: การผสานรวมกับ AWS EC2, Azure, Google Cloud Platform (GCP) GCE, OpenStack ช่วยให้ Prometheus สามารถค้นหาอินสแตนซ์ตามแท็กหรือเมตาดาต้า
• ตาม DNS: การค้นหาเป้าหมายผ่านระเบียน DNS
• ตามไฟล์: สำหรับเป้าหมายแบบคงที่หรือการผสานรวมกับระบบค้นหาแบบกำหนดเอง

การค้นพบแบบไดนามิกนี้มีความสำคัญอย่างยิ่งสำหรับการปรับใช้ทั่วโลก เนื่องจากช่วยให้การกำหนดค่า Prometheus เดียวสามารถปรับให้เข้ากับการเปลี่ยนแปลงโครงสร้างพื้นฐานในภูมิภาคหรือคลัสเตอร์ต่างๆ โดยไม่ต้องมีการแทรกแซงด้วยตนเอง เพื่อให้แน่ใจว่าการตรวจสอบอย่างต่อเนื่องเมื่อบริการเปลี่ยนแปลงและปรับขนาดทั่วโลก

PromQL: ภาษาคิวรีอันทรงพลัง

Prometheus Query Language (PromQL) เป็นภาษาคิวรีเชิงฟังก์ชันที่ช่วยให้ผู้ใช้สามารถเลือกและรวมกลุ่มข้อมูลอนุกรมเวลา มีความหลากหลายอย่างไม่น่าเชื่อ ช่วยให้คิวรีที่ซับซ้อนสำหรับการสร้างแดชบอร์ด การแจ้งเตือน และการวิเคราะห์ตามต้องการ นี่คือการดำเนินการพื้นฐานและตัวอย่างที่เกี่ยวข้องกับ APM:

• การเลือกอนุกรมเวลา:
  http_requests_total{job="api-service", status="200"}
  สิ่งนี้จะเลือกเคาน์เตอร์คำขอ HTTP ทั้งหมดจาก job api-service ที่มีรหัสสถานะ 200
• อัตราการเปลี่ยนแปลง:
  rate(http_requests_total{job="api-service", status=~"5.."}[5m])
  คำนวณอัตราเฉลี่ยต่อวินาทีของข้อผิดพลาด HTTP 5xx ในช่วง 5 นาทีที่ผ่านมา สิ่งนี้มีความสำคัญอย่างยิ่งต่อการระบุการเสื่อมสภาพของบริการ
• การรวมกลุ่ม (Aggregation):
  sum by (region) (rate(http_requests_total{job="api-service"}[5m]))
  รวมอัตราคำขอทั้งหมดสำหรับบริการ API โดยจัดกลุ่มผลลัพธ์ตาม region สิ่งนี้ช่วยให้สามารถเปรียบเทียบปริมาณคำขอในระหว่างการปรับใช้ทางภูมิศาสตร์ที่แตกต่างกัน
• Top K:
  topk(5, sum by (handler) (rate(http_requests_total[5m])))
  ระบุ top 5 handlers API ตามอัตราคำขอ ช่วยระบุ endpoint ที่มีการใช้งานมากที่สุด
• Histogram Quantiles (SLIs):
  histogram_quantile(0.99, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))
  คำนวณเปอร์เซ็นไทล์ที่ 99 ของระยะเวลาการตอบสนอง HTTP สำหรับแต่ละบริการในช่วง 5 นาทีที่ผ่านมา นี่คือเมตริกที่สำคัญสำหรับ Service Level Objectives (SLOs) แสดงให้เห็นว่าคำขอเปอร์เซ็นต์เท่าใดที่อยู่ในช่วงความหน่วงเวลาที่ยอมรับได้ หากบริการระดับโลกมี SLO ที่ 99% ของคำขอควรเสร็จสิ้นภายใน 200 มิลลิวินาที คิวรีนี้จะตรวจสอบสิ่งนั้นโดยตรง
• การดำเนินการทางคณิตศาสตร์:
  (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))) * 100
  คำนวณเปอร์เซ็นต์ของข้อผิดพลาด 5xx จากคำขอ HTTP ทั้งหมด ให้ค่าอัตราข้อผิดพลาดสำหรับระบบทั้งหมด ซึ่งมีความสำคัญต่อการตรวจสอบสุขภาพระดับโลก

การเชี่ยวชาญ PromQL เป็นกุญแจสำคัญในการปลดล็อกศักยภาพ APM เต็มรูปแบบของ Prometheus ช่วยให้นักวิศวกรสามารถถามคำถามเฉพาะเกี่ยวกับประสิทธิภาพและพฤติกรรมของแอปพลิเคชันของตน

การใช้งาน Prometheus สำหรับ APM: คู่มือระดับโลก

การปรับใช้ Prometheus สำหรับ APM ในสภาพแวดล้อมที่กระจายตัวทั่วโลกต้องอาศัยการวางแผนอย่างรอบคอบและแนวทางเชิงกลยุทธ์ นี่คือคู่มือที่ครอบคลุมขั้นตอนการใช้งานที่สำคัญ:

Instrumentation: รากฐานของการสังเกตการณ์

APM ที่มีประสิทธิภาพเริ่มต้นด้วยการทำเครื่องหมายแอปพลิเคชันอย่างเหมาะสม หากไม่มีเมตริกที่กำหนดไว้อย่างดี ระบบการตรวจสอบที่ซับซ้อนที่สุดก็ยังคงมองไม่เห็น

• การเลือก Client Libraries: Prometheus นำเสนอไลบรารีไคลเอ็นต์อย่างเป็นทางการและที่ดูแลโดยชุมชนสำหรับภาษาโปรแกรมยอดนิยมเกือบทั้งหมด (Go, Java, Python, Ruby, Node.js, C#, PHP, Rust, ฯลฯ) เลือกไลบรารีที่เหมาะสมสำหรับไมโครเซอร์วิสแต่ละตัว ตรวจสอบความสอดคล้องกันในการเปิดเผยเมตริก แม้จะข้ามสแต็กภาษาที่แตกต่างกัน เพื่อให้ง่ายต่อการรวมกลุ่มในภายหลัง
• การกำหนดเมตริกที่มีความหมาย: มุ่งเน้นไปที่เมตริกที่แสดงถึงแง่มุมที่สำคัญของประสิทธิภาพแอปพลิเคชันและประสบการณ์ผู้ใช้ 'สัญญาณทองคำสี่ประการ' (four golden signals) ของการตรวจสอบเป็นจุดเริ่มต้นที่ดี: ความหน่วงเวลา (latency) ปริมาณการใช้งาน (traffic) ข้อผิดพลาด (errors) และการอิ่มตัว (saturation)
• ความหน่วงเวลา: เวลาที่ใช้ในการให้บริการคำขอ (เช่น http_request_duration_seconds histogram)
• ปริมาณการใช้งาน: ความต้องการของระบบของคุณ (เช่น http_requests_total counter)
• ข้อผิดพลาด: อัตราคำขอที่ล้มเหลว (เช่น http_requests_total{status=~"5.."})
• การอิ่มตัว: ระบบของคุณยุ่งแค่ไหน (เช่น CPU, การใช้งานหน่วยความจำ, ความลึกของคิว - gauges)
• แนวทางปฏิบัติที่ดีที่สุดสำหรับการตั้งชื่อเมตริก: นำรูปแบบการตั้งชื่อที่สอดคล้องกันทั่วทั้งองค์กรของคุณ โดยไม่คำนึงถึงทีมหรือภาษาของบริการ ใช้ snake_case ใส่หน่วยหากมี และตั้งชื่อให้สื่อความหมาย (เช่น http_requests_total, database_query_duration_seconds)
• ตัวอย่าง: การทำเครื่องหมาย Web Service (Python Flask):

              
  from flask import Flask, request
  from prometheus_client import Counter, Histogram, generate_latest
  
  app = Flask(__name__)
  
  # Define Prometheus metrics
  REQUEST_COUNT = Counter('http_requests_total', 'Total HTTP Requests', ['method', 'endpoint', 'status'])
  REQUEST_LATENCY = Histogram('http_request_duration_seconds', 'HTTP Request Latency', ['method', 'endpoint'])
  
  @app.route('/')
  def hello_world():
      return 'Hello, World!'
  
  @app.route('/api/v1/data')
  def get_data():
      with REQUEST_LATENCY.labels(method=request.method, endpoint='/api/v1/data').time():
          # Simulate some work
          import time
          time.sleep(0.05)
          status = '200'
          REQUEST_COUNT.labels(method=request.method, endpoint='/api/v1/data', status=status).inc()
          return {'message': 'Data retrieved successfully'}
  
  @app.route('/metrics')
  def metrics():
      return generate_latest(), 200, {'Content-Type': 'text/plain; version=0.0.4; charset=utf-8'}
  
  if __name__ == '__main____':
      app.run(host='0.0.0.0', port=5000)
          
              
  
                
                  Copy
                
              
            

  ตัวอย่างง่ายๆ นี้แสดงวิธีการติดตามจำนวนคำขอและความหน่วงเวลาสำหรับ endpoint เฉพาะ ซึ่งเป็นเมตริก APM พื้นฐาน การเพิ่มป้ายกำกับสำหรับภูมิภาค ID อินสแตนซ์ หรือ ID ผู้เช่า ทำให้เมตริกเหล่านี้มีประโยชน์ในระดับโลก

กลยุทธ์การปรับใช้สำหรับขอบเขตทั่วโลก

การเลือกกลยุทธ์การปรับใช้นั้นขึ้นอยู่กับขนาด การกระจายตัวทางภูมิศาสตร์ และข้อกำหนดด้านความซ้ำซ้อนของภูมิทัศน์แอปพลิเคชันของคุณ

• Standalone Instances: สำหรับองค์กรขนาดเล็กหรือสภาพแวดล้อมที่แยกจากกัน (เช่น ศูนย์ข้อมูลเดียว ภูมิภาคคลาวด์เดียว) Prometheus server เดียวก็เพียงพอแล้ว ง่ายต่อการตั้งค่าและจัดการ แต่มีความสามารถในการปรับขนาดจำกัดและไม่มีความพร้อมใช้งานสูงในตัว
• High Availability (HA) with Replication: สำหรับบริการที่สำคัญกว่า คุณสามารถปรับใช้ Prometheus servers ที่เหมือนกันสองเครื่องซึ่งสแกนเป้าหมายเดียวกัน Alertmanager สามารถรับการแจ้งเตือนจากทั้งสองเครื่อง เพื่อให้มั่นใจในความซ้ำซ้อน แม้ว่าสิ่งนี้จะให้ HA สำหรับระบบการตรวจสอบเอง แต่ก็ไม่ได้แก้ปัญหาการรวมข้อมูลทั่วโลก
• Regional Prometheus Deployments: ในการตั้งค่าทั่วโลก เป็นเรื่องปกติที่จะปรับใช้ Prometheus server (หรือคู่ HA) ภายในแต่ละภูมิภาคทางภูมิศาสตร์ (เช่น us-east-1, eu-central-1, ap-southeast-2) Prometheus แต่ละภูมิภาคจะตรวจสอบบริการภายในภูมิภาคของตน สิ่งนี้กระจายภาระงานและเก็บข้อมูลการตรวจสอบให้ใกล้กับแหล่งที่มามากขึ้น
• Global Aggregation with Thanos/Mimir/Cortex: สำหรับมุมมองระดับโลกที่แท้จริงและการจัดเก็บระยะยาว โซลูชันต่างๆ เช่น Thanos, Mimir หรือ Cortex เป็นสิ่งที่ขาดไม่ได้ ระบบเหล่านี้ช่วยให้คุณสามารถคิวรีข้อมูลข้าม Prometheus instances หลายตัว รวบรวมการแจ้งเตือน และจัดเก็บเมตริกในที่จัดเก็บออบเจกต์ (เช่น AWS S3, Google Cloud Storage) เพื่อการเก็บรักษาที่ยาวนานและการเข้าถึงทั่วโลก
• Integration with Kubernetes: Prometheus Operator ช่วยลดความซับซ้อนในการปรับใช้และจัดการ Prometheus ในคลัสเตอร์ Kubernetes มันทำงานทั่วไปโดยอัตโนมัติ เช่น การตั้งค่า Prometheus instances, Alertmanagers และการกำหนดค่าการสแกน ทำให้เป็นวิธีที่ต้องการสำหรับแอปพลิเคชันคลาวด์เนทีฟ
• Cloud Provider Considerations: เมื่อปรับใช้ข้ามผู้ให้บริการคลาวด์ที่แตกต่างกัน (AWS, Azure, GCP) ให้ใช้ประโยชน์จากกลไกการค้นหาบริการของพวกเขา ตรวจสอบให้แน่ใจว่าการเชื่อมต่อเครือข่ายและการกำหนดค่ากลุ่มความปลอดภัยอนุญาตให้ Prometheus สแกนเป้าหมายข้ามเครือข่ายส่วนตัวเสมือน (VPNs) หรือการเชื่อมต่อแบบ peer ระหว่างภูมิภาคหรือคลาวด์ หากจำเป็น

การสร้างภาพข้อมูลด้วย Grafana: แดชบอร์ดสำหรับทีมทั่วโลก

Grafana แปลงเมตริก Prometheus ดิบให้เป็นแดชบอร์ดที่ใช้งานง่ายและโต้ตอบได้ ช่วยให้ทุกคนตั้งแต่ผู้พัฒนาไปจนถึงผู้บริหารระดับสูงเข้าใจประสิทธิภาพของแอปพลิเคชันได้อย่างรวดเร็ว

• การสร้างแดชบอร์ดที่มีประสิทธิภาพ:
• แดชบอร์ดภาพรวม: เริ่มต้นด้วยแดชบอร์ดระดับสูงที่แสดงสุขภาพโดยรวมของแอปพลิเคชันทั้งหมดหรือบริการหลักทั่วโลก (เช่น อัตราคำขอทั้งหมด อัตราข้อผิดพลาดทั่วโลก ค่าเฉลี่ยความหน่วงเวลาทั่วทุกภูมิภาค)
• แดชบอร์ดเฉพาะบริการ: สร้างแดชบอร์ดโดยละเอียดสำหรับไมโครเซอร์วิสแต่ละตัว โดยมุ่งเน้นที่ KPI ที่ไม่เหมือนใคร (เช่น ความหน่วงเวลา API เฉพาะ เวลาสอบถามฐานข้อมูล ความลึกของคิวข้อความ)
• แดชบอร์ดภูมิภาค: อนุญาตให้ทีมกรองแดชบอร์ดตามภูมิภาคทางภูมิศาสตร์ (โดยใช้ตัวแปรเทมเพลตของ Grafana ที่แมปกับป้ายกำกับ Prometheus) เพื่อเจาะลึกปัญหาประสิทธิภาพเฉพาะที่อย่างรวดเร็ว
• แดชบอร์ดที่มุ่งเน้นธุรกิจ: แปลงเมตริกทางเทคนิคให้เป็น KPI ที่เกี่ยวข้องกับธุรกิจ (เช่น อัตราการแปลง อัตราการชำระเงินที่สำเร็จ อัตราการเข้าสู่ระบบของผู้ใช้สำเร็จ) สำหรับผู้มีส่วนได้ส่วนเสียที่อาจไม่เชี่ยวชาญด้านเทคนิค
• ตัวชี้วัดประสิทธิภาพหลัก (KPIs) สำหรับแอปพลิเคชันที่หลากหลาย:
• เว็บเซอร์วิส: อัตราคำขอ อัตราข้อผิดพลาด ความหน่วงเวลา (P50, P90, P99) การเชื่อมต่อที่ใช้งานอยู่ การใช้งาน CPU/หน่วยความจำ
• ฐานข้อมูล: ความหน่วงเวลาการคิวรี การเชื่อมต่อที่ใช้งานอยู่ จำนวนการคิวรีช้า I/O ดิสก์ อัตราการเข้าถึงแคช
• คิวข้อความ: อัตราการส่ง/รับข้อความ ความลึกของคิว Lag ของผู้บริโภค
• งานแบตช์: ระยะเวลาของงาน อัตราความสำเร็จ/ความล้มเหลว การประทับเวลาการรันล่าสุด
• การกำหนดค่าการแจ้งเตือนใน Grafana: แม้ว่า Alertmanager จะเป็นกลไกการแจ้งเตือนหลัก แต่ Grafana ก็อนุญาตให้คุณกำหนดการแจ้งเตือนตามเกณฑ์แบบง่ายๆ ได้โดยตรงจากพาเนล ซึ่งมีประโยชน์สำหรับการแจ้งเตือนเฉพาะแดชบอร์ด หรือสำหรับการสร้างต้นแบบอย่างรวดเร็ว สำหรับการผลิต ให้รวมศูนย์การแจ้งเตือนใน Alertmanager

การแจ้งเตือนด้วย Alertmanager: การแจ้งเตือนทันเวลา ทั่วโลก

Alertmanager มีความสำคัญอย่างยิ่งในการแปลงการแจ้งเตือน Prometheus ให้เป็นการแจ้งเตือนที่นำไปปฏิบัติได้ เพื่อให้แน่ใจว่าผู้คนที่เหมาะสมจะได้รับแจ้งในเวลาที่เหมาะสม ทั่วทั้งภูมิภาคทางภูมิศาสตร์และโครงสร้างองค์กรที่แตกต่างกัน

• การกำหนดกฎการแจ้งเตือน: การแจ้งเตือนถูกกำหนดใน Prometheus ตามคิวรี PromQL ตัวอย่างเช่น:

            
- alert: HighErrorRate
  expr: (sum(rate(http_requests_total{job="api-service", status=~"5.."}[5m])) by (service, region) / sum(rate(http_requests_total{job="api-service"}[5m])) by (service, region)) * 100 > 5
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.service }} has a high error rate in {{ $labels.region }}"
    description: "The {{ $labels.service }} in {{ $labels.region }} is experiencing an error rate of {{ $value }}% for over 5 minutes."
        
            

              
                Copy
              
            
          

กฎนี้จะทริกเกอร์การแจ้งเตือนหากบริการ API ใดๆ ในภูมิภาคใดก็ตามมีอัตราข้อผิดพลาดเกิน 5% เป็นเวลา 5 นาทีติดต่อกัน ป้ายกำกับ service และ region ทำให้การแจ้งเตือนมีบริบทที่สมบูรณ์

• การจัดกลุ่มและการปิดเสียงการแจ้งเตือน: Alertmanager สามารถจัดกลุ่มการแจ้งเตือนที่คล้ายกัน (เช่น อินสแตนซ์ของบริการเดียวกันหลายตัวล้มเหลว) ให้เป็นการแจ้งเตือนเดียว เพื่อป้องกันการแจ้งเตือนที่มากเกินไป การปิดเสียงสามารถระงับการแจ้งเตือนชั่วคราวสำหรับช่วงเวลาบำรุงรักษาตามแผนหรือปัญหาที่ทราบ
• กฎการยับยั้ง: กฎเหล่านี้จะป้องกันไม่ให้การแจ้งเตือนที่มีลำดับความสำคัญต่ำกว่าถูกทริกเกอร์หากมีการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าสำหรับส่วนประกอบเดียวกันนั้นทำงานอยู่แล้ว (เช่น อย่าแจ้งเตือนเกี่ยวกับ CPU usage สูงหากเซิร์ฟเวอร์ล่มไปแล้วทั้งหมด)
• การผสานรวม: Alertmanager รองรับช่องทางการแจ้งเตือนที่หลากหลาย ซึ่งสำคัญสำหรับทีมทั่วโลก:
  • แพลตฟอร์มการสื่อสาร: Slack, Microsoft Teams, PagerDuty, VictorOps, Opsgenie สำหรับการสื่อสารทีมทันทีและการหมุนเวียนผู้ปฏิบัติงาน (on-call rotations)
  • อีเมล: สำหรับการแจ้งเตือนที่เร่งด่วนน้อยกว่าหรือการเผยแพร่ในวงกว้าง
  • Webhooks: สำหรับการผสานรวมกับระบบจัดการเหตุการณ์ที่กำหนดเองหรือเครื่องมือภายในอื่นๆ

  สำหรับการดำเนินงานทั่วโลก ตรวจสอบให้แน่ใจว่าการกำหนดค่า Alertmanager ของคุณพิจารณาเขตเวลาที่แตกต่างกันสำหรับตารางการทำงานของผู้ปฏิบัติงานและการส่งต่อ ตัวอย่างเช่น การแจ้งเตือนที่สำคัญในช่วงเวลาทำการของยุโรปอาจส่งไปยังทีมหนึ่ง ในขณะที่การแจ้งเตือนในช่วงเวลาทำการของเอเชียจะส่งต่อไปยังอีกทีมหนึ่ง

Prometheus ขั้นสูงสำหรับ APM ระดับองค์กร

สำหรับองค์กรขนาดใหญ่ที่มีโครงสร้างพื้นฐานที่ซับซ้อนและกระจายตัวไปทั่วโลก การปรับปรุงการตั้งค่า Prometheus หลักมักจะเป็นสิ่งจำเป็น

การจัดเก็บข้อมูลระยะยาว: เกินกว่าการเก็บรักษาในเครื่อง

การจัดเก็บข้อมูลในเครื่องเริ่มต้นของ Prometheus มีประสิทธิภาพสูง แต่ถูกออกแบบมาสำหรับการเก็บรักษาในระยะสั้น (หลายสัปดาห์ถึงหลายเดือน) เพื่อการปฏิบัติตามข้อกำหนด การวิเคราะห์ย้อนหลัง การวางแผนความจุ และการวิเคราะห์แนวโน้มตลอดหลายปี โซลูชันการจัดเก็บข้อมูลระยะยาวจึงเป็นสิ่งจำเป็น โซลูชันเหล่านี้มักใช้ที่จัดเก็บออบเจกต์ ซึ่งมอบความทนทานสูงและความคุ้มค่าสำหรับข้อมูลปริมาณมหาศาล

• Thanos: ชุดส่วนประกอบที่เปลี่ยนการปรับใช้ Prometheus ให้เป็นระบบการตรวจสอบที่มีความพร้อมใช้งานสูง หลายผู้เช่า และสามารถคิวรีได้ทั่วโลก ส่วนประกอบสำคัญประกอบด้วย:
  • Sidecar: อยู่เคียงข้าง Prometheus อัปโหลดข้อมูลย้อนหลังไปยังที่จัดเก็บออบเจกต์
  • Querier: ทำหน้าที่เป็นเกตเวย์คิวรี ดึงข้อมูลจาก Prometheus instances หลายตัว (ผ่าน Sidecar) และที่จัดเก็บออบเจกต์
  • Store Gateway: เปิดเผยข้อมูลที่จัดเก็บออบเจกต์ให้กับ Querier
  • Compactor: ลดขนาดและรวมข้อมูลเก่าในที่จัดเก็บออบเจกต์

  Thanos ช่วยให้สามารถมองเห็นคิวรีทั่วโลกแบบรวมศูนย์ข้าม Prometheus instances ภูมิภาคหลายแห่ง ทำให้เหมาะสำหรับ APM แบบกระจาย

• Mimir และ Cortex: โซลูชันการจัดเก็บข้อมูลระยะยาวที่มีความสามารถในการปรับขนาดแนวนอนสำหรับเมตริก Prometheus ออกแบบมาสำหรับการปรับใช้แบบหลายผู้เช่า ที่มีความพร้อมใช้งานสูง และกระจายตัวไปทั่วโลก ทั้งสองใช้ที่จัดเก็บออบเจกต์และให้ API ที่เข้ากันได้กับ Prometheus สำหรับการคิวรี เหมาะอย่างยิ่งสำหรับองค์กรที่ต้องการรวมศูนย์การตรวจสอบสำหรับบริการหลายพันรายการและข้อมูลเพตะไบต์จากภูมิภาคต่างๆ

Federation: การตรวจสอบข้าม Prometheus Instances ที่เป็นอิสระ

Prometheus federation ช่วยให้ Prometheus server ส่วนกลางสามารถสแกนเมตริกที่เลือกจาก Prometheus servers อื่นๆ ได้ สิ่งนี้มีประโยชน์สำหรับ:

• การตรวจสอบแบบลำดับชั้น: Prometheus ส่วนกลางสามารถสแกนเมตริกที่รวมกลุ่ม (เช่น จำนวนคำขอทั้งหมดต่อภูมิภาค) จาก Prometheus instances ภูมิภาค ในขณะที่อินสแตนซ์ภูมิภาคจะสแกนเมตริกโดยละเอียดจากบริการแต่ละรายการ
• ภาพรวมระดับโลก: ให้ภาพรวมระดับสูงของโครงสร้างพื้นฐานทั่วโลกทั้งหมดโดยไม่ต้องจัดเก็บข้อมูลที่มีรายละเอียดทั้งหมดส่วนกลาง

แม้ว่าจะมีประสิทธิภาพสำหรับกรณีการใช้งานบางอย่าง แต่ federation อาจมีความซับซ้อนสำหรับการรวมกลุ่มทั่วโลกในระดับที่ใหญ่มาก โดยปกติแล้ว Thanos หรือ Mimir จะเป็นที่ต้องการสำหรับโซลูชันที่ครอบคลุมกว่าในการคิวรีแบบกระจายและการจัดเก็บข้อมูลระยะยาว

Custom Exporters: เชื่อมช่องว่างการสังเกตการณ์

ไม่ใช่ทุกแอปพลิเคชันหรือระบบที่จะเปิดเผยเมตริก Prometheus โดยธรรมชาติ สำหรับระบบเก่า ซอฟต์แวร์ที่เป็นกรรมสิทธิ์ หรือเทคโนโลยีเฉพาะ Custom Exporters จึงจำเป็น สิ่งเหล่านี้คือโปรแกรมขนาดเล็กที่:

• เชื่อมต่อกับระบบเป้าหมาย (เช่น คิวรี REST API แยกวิเคราะห์บันทึก โต้ตอบกับฐานข้อมูล)
• ดึงข้อมูลที่เกี่ยวข้อง
• แปลงข้อมูลให้อยู่ในรูปแบบเมตริก Prometheus
• เปิดเผยเมตริกเหล่านี้ผ่านเอนด์พอยต์ HTTP เพื่อให้ Prometheus สแกน

ความยืดหยุ่นนี้ทำให้มั่นใจได้ว่าแม้แต่ระบบที่ไม่ใช่แบบเนทีฟก็สามารถรวมเข้ากับโซลูชัน APM ที่ใช้ Prometheus ได้ โดยให้มุมมองแบบองค์รวมในสภาพแวดล้อมที่หลากหลาย

ข้อควรพิจารณาด้านความปลอดภัย: การปกป้องข้อมูลการตรวจสอบของคุณ

ข้อมูลการตรวจสอบอาจมีข้อมูลที่ละเอียดอ่อนเกี่ยวกับสุขภาพและประสิทธิภาพของแอปพลิเคชันของคุณ การใช้มาตรการรักษาความปลอดภัยที่แข็งแกร่งเป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะอย่างยิ่งในการปรับใช้ทั่วโลกที่ข้อมูลข้ามเครือข่ายและเขตอำนาจศาลต่างๆ

• การแบ่งส่วนเครือข่าย: แยก Prometheus servers และ exporters ของคุณในเครือข่ายการตรวจสอบเฉพาะ
• การยืนยันตัวตนและการอนุญาต: รักษาความปลอดภัยเอนด์พอยต์ Prometheus และ Grafana ของคุณ ใช้โซลูชันเช่น OAuth2 proxies, reverse proxies พร้อม basic auth หรือผสานรวมกับผู้ให้บริการข้อมูลประจำตัวขององค์กร สำหรับการสแกน ใช้ TLS เพื่อการสื่อสารที่ปลอดภัยระหว่าง Prometheus และเป้าหมาย
• การเข้ารหัสข้อมูล: เข้ารหัสข้อมูลเมตริกทั้งในระหว่างการส่ง (TLS) และเมื่อจัดเก็บ (การเข้ารหัสดิสก์สำหรับที่จัดเก็บ Prometheus, การเข้ารหัสสำหรับโซลูชันที่จัดเก็บออบเจกต์เช่น S3)
• การควบคุมการเข้าถึง: ใช้การควบคุมการเข้าถึงตามบทบาท (RBAC) ที่เข้มงวดสำหรับแดชบอร์ด Grafana และ API Prometheus เพื่อให้แน่ใจว่าเฉพาะบุคลากรที่ได้รับอนุญาตเท่านั้นที่สามารถดูหรือแก้ไขการกำหนดค่าการตรวจสอบได้
• Prometheus Remote Write/Read: เมื่อใช้ที่จัดเก็บข้อมูลระยะไกล ตรวจสอบให้แน่ใจว่าการสื่อสารระหว่าง Prometheus และระบบที่จัดเก็บข้อมูลระยะไกลได้รับการรักษาความปลอดภัยด้วย TLS และการยืนยันตัวตนที่เหมาะสม

การวางแผนความจุและการปรับแต่งประสิทธิภาพ

เมื่อสภาพแวดล้อมที่ตรวจสอบของคุณเติบโต Prometheus เองก็ต้องการการตรวจสอบและปรับขนาด ข้อควรพิจารณา ได้แก่:

• การจัดสรรทรัพยากร: ตรวจสอบ CPU, หน่วยความจำ และ I/O ดิสก์ของ Prometheus servers ของคุณ ตรวจสอบให้แน่ใจว่ามีการจัดสรรทรัพยากรเพียงพอ โดยเฉพาะอย่างยิ่งสำหรับเมตริกที่มีคาร์ดินาลิตีสูงหรือระยะเวลาการเก็บรักษาที่ยาวนาน
• ช่วงเวลาการสแกน: ปรับช่วงเวลาการสแกนให้เหมาะสม แม้ว่าความถี่สูงจะให้ข้อมูลที่มีรายละเอียดสูง แต่ก็เพิ่มภาระให้กับเป้าหมายและ Prometheus จงรักษาสมดุลระหว่างรายละเอียดกับการใช้งานทรัพยากร
• การประเมินกฎ: กฎการแจ้งเตือนที่ซับซ้อนหรือกฎการบันทึกจำนวนมากอาจใช้ CPU จำนวนมาก ปรับคิวรี PromQL ให้เหมาะสมและตรวจสอบให้แน่ใจว่ากฎได้รับการประเมินอย่างมีประสิทธิภาพ
• Relabeling: ทิ้งเมตริกและป้ายกำกับที่ไม่ต้องการอย่างแข็งขันที่เป้าหมายการสแกนหรือระหว่างกฎ relabeling สิ่งนี้ช่วยลดคาร์ดินาลิตีและลดการใช้งานทรัพยากร

Prometheus ในการปฏิบัติ: กรณีการใช้งานระดับโลกและแนวทางปฏิบัติที่ดีที่สุด

ความอเนกประสงค์ของ Prometheus ทำให้เหมาะสำหรับ APM ในอุตสาหกรรมและรูปแบบการดำเนินงานทั่วโลกที่หลากหลาย

แพลตฟอร์มอีคอมเมิร์ซ: ประสบการณ์การช้อปปิ้งที่ราบรื่น

แพลตฟอร์มอีคอมเมิร์ซระดับโลกจำเป็นต้องแน่ใจว่าเว็บไซต์และบริการแบ็กเอนด์มีความรวดเร็วและเชื่อถือได้สำหรับลูกค้าในทุกเขตเวลา Prometheus สามารถตรวจสอบ:

• เกตเวย์การชำระเงิน: ความหน่วงเวลาและอัตราข้อผิดพลาดสำหรับการทำธุรกรรมที่ประมวลผลในสกุลเงินและภูมิภาคต่างๆ (เช่น payment_service_requests_total{gateway="stripe", currency="EUR"})
• บริการสินค้าคงคลัง: ระดับสต็อกแบบเรียลไทม์และความหน่วงเวลาในการอัปเดตสำหรับคลังสินค้าที่กระจายตัว (เช่น inventory_stock_level{warehouse_id="london-01"})
• การจัดการเซสชันผู้ใช้: เซสชันผู้ใช้ที่ใช้งานอยู่ อัตราการเข้าสู่ระบบสำเร็จ และเวลาตอบสนอง API สำหรับคำแนะนำที่ปรับให้เหมาะกับแต่ละบุคคล (เช่น user_auth_login_total{status="success", region="apac"})
• ประสิทธิภาพ CDN: อัตราการเข้าถึงแคชและความหน่วงเวลาในการจัดส่งเนื้อหาสำหรับผู้ใช้ที่กระจายตัวทางภูมิศาสตร์

ด้วย Prometheus และ Grafana ทีมสามารถระบุได้อย่างรวดเร็วว่าความล่าช้าในการชำระเงินนั้นเฉพาะเจาะจงกับผู้ให้บริการชำระเงินในประเทศใดประเทศหนึ่ง หรือปัญหาการซิงค์สินค้าคงคลังทั่วไปส่งผลกระทบต่อทุกภูมิภาคหรือไม่ ช่วยให้สามารถตอบสนองต่อเหตุการณ์ได้อย่างตรงเป้าหมายและรวดเร็ว

ผู้ให้บริการ SaaS: เวลาทำงานและประสิทธิภาพสำหรับลูกค้าที่หลากหลาย

บริษัท SaaS ที่ให้บริการฐานลูกค้าทั่วโลกต้องรับประกันความพร้อมใช้งานสูงและประสิทธิภาพที่สม่ำเสมอ Prometheus ช่วยได้โดยการติดตาม:

• เวลาทำงานและระยะเวลาของบริการ: SLIs และ SLOs สำหรับ API ที่สำคัญและคุณสมบัติที่ผู้ใช้เห็น โดยแบ่งตามภูมิภาคหรือผู้เช่าของลูกค้า (เช่น api_latency_seconds_bucket{endpoint="/dashboard", tenant_id="enterprise_asia"})
• การใช้งานทรัพยากร: CPU, หน่วยความจำ และ I/O ดิสก์สำหรับโครงสร้างพื้นฐานพื้นฐาน (VMs, คอนเทนเนอร์) เพื่อป้องกันการอิ่มตัว
• เมตริกระดับผู้เช่า: สำหรับแอปพลิเคชันแบบหลายผู้เช่า เมตริกที่กำหนดเองพร้อมป้ายกำกับ tenant_id ช่วยให้สามารถตรวจสอบการใช้ทรัพยากรและการแยกประสิทธิภาพสำหรับลูกค้าแต่ละราย ซึ่งมีความสำคัญอย่างยิ่งต่อข้อตกลงระดับบริการ (SLAs)
• การบังคับใช้โควต้า API: ติดตามขีดจำกัดการโทร API และการใช้งานต่อไคลเอ็นต์เพื่อให้แน่ใจว่ามีการใช้งานที่ยุติธรรมและป้องกันการละเมิด

สิ่งนี้ช่วยให้ผู้ให้บริการ SaaS สามารถติดต่อลูกค้าที่ประสบปัญหาเฉพาะที่เชิงรุก หรือปรับขนาดทรัพยากรในภูมิภาคเฉพาะก่อนที่ประสิทธิภาพจะเสื่อมถอยลงทั่วโลก

บริการทางการเงิน: การรับรองความสมบูรณ์ของธุรกรรมและ Latency ต่ำ

ในบริการทางการเงิน ทุกมิลลิวินาทีและทุกธุรกรรมมีความสำคัญ สถาบันการเงินระดับโลกอาศัยการตรวจสอบเพื่อรักษาการปฏิบัติตามกฎระเบียบและความไว้วางใจของลูกค้า

• การประมวลผลธุรกรรม: ความหน่วงเวลาตั้งแต่ต้นจนจบสำหรับประเภทธุรกรรมต่างๆ อัตราความสำเร็จ/ความล้มเหลว และความลึกของคิวสำหรับโบรกเกอร์ข้อความ (เช่น transaction_process_duration_seconds, payment_queue_depth)
• ฟีดข้อมูลตลาด: ความหน่วงเวลาและความสดใหม่ของข้อมูลจากตลาดการเงินทั่วโลกต่างๆ (เช่น market_data_feed_delay_seconds{exchange="nyse"})
• การตรวจสอบความปลอดภัย: จำนวนการเข้าสู่ระบบที่ล้มเหลว การเรียก API ที่น่าสงสัยจากตำแหน่งที่ไม่ปกติ
• การปฏิบัติตามข้อกำหนด: การจัดเก็บเมตริกที่เกี่ยวข้องกับการตรวจสอบในระยะยาว

Prometheus ช่วยรักษาความสมบูรณ์และความสามารถในการตอบสนองของแพลตฟอร์มการซื้อขาย แอปพลิเคชันธนาคาร และระบบการชำระเงินที่ดำเนินงานในตลาดการเงินและสภาพแวดล้อมกฎระเบียบที่แตกต่างกัน

โซลูชัน IoT: การจัดการกลุ่มอุปกรณ์ที่กระจายตัวจำนวนมาก

แพลตฟอร์ม IoT เกี่ยวข้องกับการตรวจสอบอุปกรณ์หลายล้านเครื่องที่กระจายตัวทั่วโลก โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่ห่างไกลหรือท้าทาย Pushgateway มีประโยชน์อย่างยิ่งในกรณีนี้

• สุขภาพของอุปกรณ์: ระดับแบตเตอรี่ ค่าที่วัดได้จากเซ็นเซอร์ สถานะการเชื่อมต่อจากอุปกรณ์แต่ละเครื่อง (เช่น iot_device_battery_voltage{device_id="sensor-alpha-001", location="remote-mine-site"})
• อัตราการนำเข้าข้อมูล: ปริมาณข้อมูลที่ได้รับจากประเภทอุปกรณ์และภูมิภาคต่างๆ
• ประสิทธิภาพการประมวลผลที่ Edge: การใช้งานทรัพยากรและสุขภาพของแอปพลิเคชันบนอุปกรณ์ Edge หรือเกตเวย์

Prometheus ช่วยจัดการขนาดและการกระจายตัวของ IoT นำเสนอข้อมูลเชิงลึกเกี่ยวกับสถานะการดำเนินงานของกลุ่มอุปกรณ์ทั่วโลก

สรุปแนวทางปฏิบัติที่ดีที่สุดสำหรับการ APM ระดับโลกด้วย Prometheus

• เริ่มต้นเล็กๆ ทยอยปรับปรุง: เริ่มต้นด้วยการทำเครื่องหมายบริการหลักและโครงสร้างพื้นฐานที่สำคัญ ค่อยๆ ขยายการรวบรวมเมตริกของคุณและปรับปรุงแดชบอร์ดและการแจ้งเตือนของคุณ
• มาตรฐานการตั้งชื่อเมตริกและป้ายกำกับ: ความสอดคล้องเป็นกุญแจสำคัญสำหรับความชัดเจนและการสอบถามที่ง่ายดาย โดยเฉพาะอย่างยิ่งสำหรับทีมและเทคโนโลยีที่หลากหลาย เอกสารคู่มือเกี่ยวกับเมตริกของคุณ
• ใช้ประโยชน์จากป้ายกำกับอย่างมีประสิทธิภาพ: ใช้ป้ายกำกับเพื่อเพิ่มบริบท (ภูมิภาค บริการ เวอร์ชัน ผู้เช่า ID อินสแตนซ์) หลีกเลี่ยงป้ายกำกับที่มีคาร์ดินาลิตีสูงเกินไป เว้นแต่จะจำเป็นอย่างยิ่ง เนื่องจากอาจส่งผลต่อประสิทธิภาพ
• ลงทุนในแดชบอร์ดที่มีประสิทธิภาพ: สร้างแดชบอร์ดที่ปรับให้เหมาะกับผู้ชมที่แตกต่างกัน (ภาพรวมระดับโลก การเจาะลึกระดับภูมิภาค รายละเอียดระดับบริการ KPI ทางธุรกิจ)
• ทดสอบการแจ้งเตือนของคุณอย่างเข้มงวด: ตรวจสอบให้แน่ใจว่าการแจ้งเตือนทำงานอย่างถูกต้อง ส่งไปยังทีมที่ถูกต้อง และสามารถนำไปปฏิบัติได้ หลีกเลี่ยงการแจ้งเตือนที่มีเสียงรบกวนซึ่งนำไปสู่ความเหนื่อยล้า พิจารณาการเปลี่ยนแปลงเกณฑ์ตามภูมิภาคหากลักษณะประสิทธิภาพแตกต่างกัน
• วางแผนสำหรับการจัดเก็บระยะยาวตั้งแต่เนิ่นๆ: สำหรับการปรับใช้ทั่วโลกที่ต้องการการเก็บรักษาข้อมูลอย่างกว้างขวาง ให้รวม Thanos, Mimir หรือ Cortex ตั้งแต่แรกเริ่ม เพื่อหลีกเลี่ยงความซับซ้อนในการย้ายข้อมูลในภายหลัง
• เอกสารทุกอย่าง: บำรุงรักษาเอกสารประกอบที่ครอบคลุมเกี่ยวกับการตั้งค่าการตรวจสอบของคุณ รวมถึงคำจำกัดความของเมตริก กฎการแจ้งเตือน และรูปแบบแดชบอร์ด สิ่งนี้มีค่าอย่างยิ่งสำหรับทีมทั่วโลก

ความท้าทายและข้อควรพิจารณา

แม้ว่า Prometheus จะเป็นเครื่องมือที่ทรงพลังอย่างยิ่งสำหรับ APM แต่องค์กรควรตระหนักถึงความท้าทายที่อาจเกิดขึ้น:

• ภาระงานในการดำเนินงาน: การจัดการสแต็กการตรวจสอบที่ใช้ Prometheus (Prometheus servers, Alertmanagers, Grafana, exporters, Thanos/Mimir) อาจต้องใช้ความเชี่ยวชาญในการดำเนินงานเฉพาะ โดยเฉพาะอย่างยิ่งในระดับใหญ่ การทำให้การปรับใช้และการกำหนดค่าเป็นอัตโนมัติ (เช่น การใช้ Kubernetes Operators) ช่วยลดปัญหานี้ได้
• เส้นโค้งการเรียนรู้: PromQL แม้จะมีประสิทธิภาพ แต่ก็มีเส้นโค้งการเรียนรู้ ทีมจำเป็นต้องลงทุนเวลาในการฝึกอบรมเพื่อใช้ประโยชน์จากความสามารถของมันอย่างเต็มที่สำหรับการคิวรีที่ซับซ้อนและการแจ้งเตือนที่เชื่อถือได้
• ความต้องการทรัพยากรสำหรับคาร์ดินาลิตีสูง: หากไม่ได้รับการจัดการอย่างระมัดระวัง เมตริกที่มีชุดค่าผสมป้ายกำกับที่ไม่ซ้ำกันจำนวนมาก (คาร์ดินาลิตีสูง) อาจใช้หน่วยความจำและ I/O ดิสก์จำนวนมากบน Prometheus server ซึ่งอาจส่งผลกระทบต่อประสิทธิภาพ การใช้ relabeling อย่างมีกลยุทธ์และการออกแบบป้ายกำกับอย่างรอบคอบเป็นสิ่งจำเป็น
• กลยุทธ์การเก็บรักษาข้อมูล: การรักษาสมดุลระหว่างความต้องการข้อมูลย้อนหลังกับต้นทุนการจัดเก็บและประสิทธิภาพอาจเป็นเรื่องท้าทาย โซลูชันการจัดเก็บข้อมูลระยะยาวแก้ไขปัญหานี้ แต่เพิ่มความซับซ้อน
• ความปลอดภัย: การรับรองการเข้าถึงที่ปลอดภัยไปยังเอนด์พอยต์เมตริกและระบบการตรวจสอบเองนั้นเป็นสิ่งสำคัญ โดยต้องมีการกำหนดค่าความปลอดภัยเครือข่าย การยืนยันตัวตน และการอนุญาตอย่างรอบคอบ

บทสรุป

Prometheus ได้สร้างสถานะของตนเองอย่างมั่นคงในฐานะเสาหลักของการตรวจสอบประสิทธิภาพแอปพลิเคชันยุคใหม่ โดยเฉพาะอย่างยิ่งสำหรับสถาปัตยกรรมคลาวด์เนทีฟและไมโครเซอร์วิสที่ทำงานทั่วโลก โมเดลแบบดึง (pull-based model) โมเดลข้อมูลหลายมิติพร้อมป้ายกำกับ PromQL ที่ทรงพลัง และระบบนิเวศที่กว้างขวาง ทำให้มีความสามารถที่เหนือชั้นในการได้รับข้อมูลเชิงลึกที่ลึกซึ้งและนำไปปฏิบัติได้เกี่ยวกับสุขภาพและประสิทธิภาพของแอปพลิเคชันแบบกระจาย

สำหรับองค์กรที่ดำเนินงานในภูมิภาคทางภูมิศาสตร์ที่หลากหลายและให้บริการฐานลูกค้าทั่วโลก Prometheus นำเสนอความยืดหยุ่น ความสามารถในการปรับขนาด และการมองเห็นที่จำเป็นในการรักษาข้อกำหนดระดับบริการที่สูง ระบุและแก้ไขปัญหาได้อย่างรวดเร็ว และเพิ่มประสิทธิภาพแอปพลิเคชันอย่างต่อเนื่อง ด้วยการนำ Prometheus มาใช้ องค์กรสามารถก้าวจากการแก้ไขปัญหาเชิงปฏิกิริยาไปสู่การตรวจจับปัญหาเชิงรุก เพื่อให้มั่นใจว่าบริการดิจิทัลของตนจะยังคงมีความยืดหยุ่น ตอบสนอง และเชื่อถือได้ ไม่ว่าผู้ใช้จะอยู่ที่ใดก็ตาม

เริ่มต้นการเดินทางของคุณสู่ APM ที่เหนือกว่าวันนี้ เริ่มต้นทำเครื่องหมายแอปพลิเคชันของคุณ สร้างแดชบอร์ดที่ให้ข้อมูลเชิงลึกด้วย Grafana และสร้างการแจ้งเตือนที่แข็งแกร่งด้วย Alertmanager เข้าร่วมชุมชนระดับโลกที่ใช้ Prometheus เพื่อเชี่ยวชาญความซับซ้อนของภูมิทัศน์แอปพลิเคชันยุคใหม่ และส่งมอบประสบการณ์ผู้ใช้ที่ยอดเยี่ยมทั่วโลก